iT邦幫忙

2023 iThome 鐵人賽

DAY 12
2
DevOps

Observability 101系列 第 12

Day12 - 可觀察性的演進史:從控制理論到重新定義

  • 分享至 

  • xImage
  •  

鐵人賽 Day12 - 可觀察性的演進史:從控制理論到重新定義

大家好,我是伐伐伐伐木工

今天要與大家分享關於可觀測性過去幾年是如何不斷演進與重新定義的歷程

演進史

https://ithelp.ithome.com.tw/upload/images/20230927/20162577XGL1LXhorT.png

1960:可觀測性和控制理論

  • 在技術領域,可觀測性一詞 起源於控制理論,這是動態工程和機械系統的數學領域
  • 在系統中,可觀測性是衡量系統內部狀態可以從外部輸出的知識推斷出來的程度的指標。
  • 魯道夫·E·卡爾曼 (Rudolf E. Kálmán) 引入了該術語來描述系統可以透過其產出來衡量的程度。

2013:Twitter 可觀測團隊描述其使命

  • 2013.9 : Twitter 的工程師撰寫了一篇名為Twitter 的可觀察性的部落格文章,「可觀察性」一詞首次在 IT 系統中登場,內文如下

Twitter 的工程師需要確定其服務的性能特徵、對上游和下游服務的影響,並在服務未按預期運行時收到通知。
可觀察性團隊的使命是利用我們用於收集、儲存和呈現指標的統一平台來分析此類問題。解釋了如何「捕獲、儲存、查詢、視覺化和自動化整個過程」

2016:Twitter 可觀察性的(四個)支柱

Twitter 的可觀測性工程團隊為我們的內部工程團隊提供全端程式庫和多種服務,以監控服務運作狀況、發出問題警報、透過提供分散式系統呼叫追蹤來支援根本原因調查,並通過創建聚合應用程序/系統日誌的可搜尋索引。

  • 其中概述了他們團隊章程的四大支柱
    • 監控
    • 警報/可視化
    • 分散式系統追蹤基礎設施
    • 日誌聚合/分析

2017:可觀察性的三大支柱

  • 2017.2 : Peter Bourgon 出席2017分散式追蹤高峰會。他參與了關於追蹤如何幫助提供可觀察性的定義和範圍的討論
  • 在一篇名為 「指標、追蹤和日誌記錄」的部落格文章中,他描述了他認為他們如何可能將儀器或可觀察性領域繪製成一種維恩圖
    https://ithelp.ithome.com.tw/upload/images/20230927/20162577aDTq7hfSUR.png

2018:可觀測年

  • 可觀察性以及日誌記錄、指標和追蹤三大支柱成為主流對話的一部分。
  • 2018.6,Humio 執行長 Geeta Schmidt在一篇名為《數據驅動的可觀察性和日誌》的Medium 文章中加入了她的想法。

僅僅擁有用於日誌管理、指標和追蹤的工具並不足以從中獲得價值。她堅持認為需要進行文化轉變,重視事實和回饋,在調試過程中以數據為驅動。並利用這種思維方式來迭代、改進和解決問題。

  • 2018.7,Cindy Sridharan為 O'Reilly 出版了一本權威書籍 分散式系統可觀察性。本書概述了可觀察性的三大支柱,並詳細介紹了使用哪些工具以及何時使用。
  • 2018 年底,可觀測三大支柱模式開始出現裂痕。
  • 2018.9 Honeycomb 技術長 Charity Majors 警告稱

可觀察性描述為三大支柱限制了討論。大膽地感嘆“可觀測性不存在三大支柱”,並補充道,“事實上,每個人都在盲目地重複這個口頭禪(以及貨物崇拜這些原語),這可能就是為什麼我們的可觀測性工具落後了10 年。
”我們軟體工具鏈的其餘部分。” 她進一步指出:「事件是程式碼通過系統的執行路徑。這是從內到外了解您的系統的正確視角。”

許多業內人士注意到了這一點,並開始考慮除了三大支柱之外的可觀察性。

2019:激烈辯論隨之而來

https://ithelp.ithome.com.tw/upload/images/20230927/20162577Xa5Ug7ou0q.png
隨著越來越多人重視與實際導入,可觀測性議題開始慢慢浮現

當公司購買並部署工具來從三個支柱中收集數據時,他們發現他們可以存取更多的系統數據,但他們仍然沒有實現基礎設施的 100% 可觀察性。
事實證明,承諾可觀察性的工具無法處理來自 TB 級非結構化資料的資料量。工程師必須限制他們保留的數據,以保持在昂貴的許可證所限制的範圍內。他們發現他們使用的工具太慢,因為索引延遲和其他問題導致即時觀察變得不可能。而且新系統過於複雜,部署困難、維護不切實際且成本高、介面不一致、難學、難用。

整個產業的技術領導者加入了重新定義可觀察性的對話。

2019.2,LightStep 執行長兼聯合創始人Ben Sigelman發表了一篇名為《 零答案的三大支柱:可觀察性的新記分卡》的部落格文章。

他描述了高基數指標如何壓倒系統。他指出,如果您想要攝取、保留和儲存來自分散式系統的大量數據,日誌就會變得太昂貴。如果您無法確定正確的樣本,那麼痕跡就會變得不切實際。他指出,即使所有這些都可以克服,但 這些都不能直接解決特定的痛點、用例或業務需求。

2019.8,Glitch 的站點可靠性工程師Mads Hartmann在幾個月內深入研究了可觀察性,並在《可觀察性之旅:閱讀材料》中發表了他的想法。他的結論是,您無法僅透過系統產生的遙測(記錄和傳輸儀器讀數的過程)來實現可觀測性

他提出了可觀察性的另一種觀點:

……可觀察性就是能夠向系統提出問題並根據其產生的現有遙測數據獲得答案;如果您必須重新配置或修改服務才能獲得問題的答案,那麼您還沒有實現可觀察性。

Mads Hartmann 同意麥茲的前進方向。2019 年 8 月,她在 The New Stack: Observability — A 3-Year Retrospective上發表文章 。在其中,她領導了一項挑戰,為可觀察性提出了新的定義:

如果我們不使用「可觀察性」來表示已知的未知與未知的未知之間、被動監控與探索性調試之間的差異,則不清楚我們還可以使用哪些其他術語(也不清楚同樣的命運不會降臨到它們身上)

她接著建議,實現可觀察性的承諾來自於能夠檢查系統的內部狀態並能夠提出任何問題來理解它。

透過使用事件並傳遞完整的上下文,相反,我可以詢問我的系統的任何問題並檢查其內部狀態,因此我可以理解我的系統已經進入的任何狀態- 即使我以前從未見過它,從未想到過它之前!我可以理解系統內發生的任何事情、系統可能處於的任何狀態,而無需發布新程式碼來處理狀態。這是關鍵。這就是可觀察性

2020:可觀察性(重新)定義

2020.11 CNCF TAG 小組開始撰寫可觀測性白皮書,至今內容仍在撰寫中

可觀測性不僅僅是三種類型資料的部署和收集。可觀察性是你要麼擁有,要麼沒有的東西。只有當您擁有所有數據來回答任何問題(無論是否可預測)時,它才能實現。我們同意那些這樣想的人:

可觀察性是指您能夠從系統提供的資料中了解系統的內部狀態,並且您可以探索該資料來回答有關發生了什麼以及為什麼發生的任何問題。

就像是世紀帝國中,主城鎮在演進的過程中隨著不同時代(封建時期、城堡時期、帝王時代)而在外觀上會有不一樣的變化,其核心價值與精神是保持不變的,要真正了解所面臨到的問題跟挑戰,我們更需要的是深入探討這些演變的過程與其目的。
https://ithelp.ithome.com.tw/upload/images/20230927/20162577jl3PXBzm6U.png

接下來會怎麼發展,近幾年自己觀察到有些議題越來越火

  • OpenTelemetry 是分散式追蹤的新的規範,開發者可以深入了解應用程式的運行狀態,透過工具的配合可以更有效的掌握系統的全貌。
  • 數據可觀察性(Data Observability)是希望透過收集數據,能夠更直觀的理解與解讀數據。
  • 可觀測性驅動開發(O.D.D)是提供新的思考方式 (左移),期許開發者可以從可觀測性的角度出發,確保系統在任何狀態下都可以提供清晰、有意義的呈現與回饋。
  • eBPF 是一項革命性的技術,讓開發者可以在不改變核心代碼的情況下,對 Linux 系統進行深度觀察與修改。其特性也將成為下一代系統診斷與優化的關鍵工具。

OpenTelemetry 與可觀測性驅動開發之後(應該)會有章節來介紹,未來會怎麼發展讓我們繼續看下去 XDDD

以上是今天的分享。下一篇要來探討 Observability Signals,如果有任何疑問或想法,歡迎留言提出討論 !

小結

  • 可觀察性是指您能夠從系統提供的資料中了解系統的內部狀態,並且您可以探索該資料來回答有關發生了什麼以及為什麼發生的任何問題。

參考連結

Observability is Also Programmed

Observability (Re)defined


上一篇
Day11 - 解析監控和可觀測性:從哨塔到全景地圖
下一篇
Day13 - 可觀測性信號(Signals)的進化之旅
系列文
Observability 10131
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言